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METHOD OF AND SYSTEM FOR PROVIDING QUALITY OF 
SERVICE IN LP TELEPHONY 



5 The present invention relates generally to the field of Internet telephony, and more particularly 

to a method of and system for providing quality of service in an Internet telephony session 

Two trends are currently occurring in the telecommunications marketplace. First, telephony 
services are being added to Internet protocol-based devices. Second, Asynchronous Transfer Mode 
(ATM) networks are being built with the ability to support user specified quality of service (QoS) on a 

10 per connection basis, as part of the ATM switched virtual circuit service capability. 

Each of these trends have problems. The primary problem with the introduction of telephony 
services to the IP network is one providing predictable QoS on a per call/connection basis. Although 
teclmologies are being developed in the Internet community to address this problem, there is currently 
no way to guarantee QoS on a per connection basis tlirough an IP network. The primary problem with 

15 the second trend is not one of basic service capability, but is rather one of access to the service. Today 
virtually all desktop devices have access to an EP network through some sort of local area network 
technology, for example tlirough Ethernet. The problem is that these desktop devices generally do not 
have access to ATM networks that provide the per call/connection guarantee QoS. 

The primary method of addressing QoS in the current IP-BASED networks is to over- 

20 provision the amount of bandwidth available in the network. Tliis approach will work as long as the 
usage of the network stays witliin the bounds of the available bandwidth. If the usage of the network is 
not predictable, then it is difficult, for example, to prevent a low priority file transfer from interfering 
with a connection established to carry real-time voice or video data. 

The primary method of providing ATM switched virtual circuit services to devices that do not 

25 have native ATM support is to install routers between the IP network and the ATM network that have 
the ability to generate ATM switched virtual circuits on a per IP flow basis. The problems with this 
approach are: (1) possible destination IP addresses need to be provisioned in the router ahead of time, 
and (2) it is not possible to define, on an IP flow basis, which IP flow should get the ATM switched 
virtual circuit service and which should get IP best efforts service. If a destination address is 

30 provisioned in the ATM interworking router, then all connections to that destination address will 
require an ATM switched virtual circuit. 

1 
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The present invention provides a method of and a system for providing quality of service in an 
IP telephony session between a calling party client and a called party client. The system of the present 
invention establishes a high quality of service ATM virtual circuit for the session between first and 

5 second devices, each of the devices having ATM capability and IP capability. The first and second 
devices provide bidirectional translation between Internet Protocol (IP) media and ATM media. The 
system transports IP media for the session between the calling party client and the first device, and 
between the called party client and the second device. The virtual circuit transports ATM media for 
the session between the first and second devices. An intelligent control layer provides IP and ATM 

1 0 signaling to set up the session. 

In one embodiment of the present invention, the first and second devices include access control 
managers that are bridges between an IP network and an ATM network. The intelligent control layer 
assigns a temporary session IP proxy address for the called party at the first access control manager 
and a temporary session IP proxy address for the calling party at the second access control manager. 

1 5 The system esUblishes a switched virtual circuit through the ATM network for the session between the 
first access control man aper and the second access control manager by assigning a temporary session 
calling party num ber at the first access control manager and a temporary session called party number at 
the second access control manager. 

During the session, the system routes IP media from the calling party to the temporary IP 

20 proxy address of the called party at the first access control manager. The first access control manager 
packages the IP media in ATM cells for transport through the virtual circuit to the second access 
control manager. The system then routes IP media from the second access control manager to the 
called party. Similarly, die system routes IP media from the called party to the temporary IP proxy 
address of the calling party at the second access control manager. The second access control manager 

25 packages the IP media in ATM ceils for transport through the virtual circuit to the first access control 
manager. The system then routes IP media from the first access control manager to the calling party. 

In an alternative embodiment, the first and second devices include routers that have both IP and 
ATM capability. The calling party client obtains an authentication ticket and then initiates an IP 
telephony session with a quality of service request When the called party client accepts the session, 

30 the calling party client initiates setup of a resource reservation protocol IP media session with an 
ingress router. The ingress router then sets up the IP media session through an egress router to tta 
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called party client. When the IP media session is setup, the ingress router sets up an ATM switched 
virtual connection with the egress router. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of a preferred embodiment of the system of the present invention. 
Fig. 2 is a call flow diagram illustrating the signaling and call setup according to the 
embodiment of Fig. 1. 

Fig. 3 is a block diagram of an alternative embodiment of the system of the present invention. 
Fig. 4 is a call flow diagram illustrating the signaling and call setup according to the 
10 embodiment of Fig. 3. 

DETAILED DESCRIPTION 

Referring now to the drawings, and first to Fig. 1, a system according to a preferred 
embodiment of the present invention is designated generally by the numeral 1 1. System 1 1 includes a 
media service control point (MSCP) 13. MSCP 13 includes an IP telephony session establishment 
server, wliich in the preferred embodiment is a session initiation protocol (SIP) server 15, an ingress 
Asynchronous Transfer Mode (ATM) MSCP 17, and an egress ATM MSCP 19. As will be explained 
in detail hereinafter, MSCP 13 provides an intelligent control layer for the establishment of an Internet 
Protocol (IP) telephony session between a first IP telephony user client 21 and a second IP telephony 
20 user client 23. 

System 1 1 includes an ingress access control manager 25 and an egress access control manager 
27. Access control managers 25 and 27 provide a media gateway between IP telephony user clients 21 
and 23 and an ATM network 27. Ingress access control manager 25 provides an ATM media and 
signaling interface to an ingress ATM switch 29 of ATM network 27. Similarly, egress access control 
manager 27 provides an ATM media and signaling interface to an egress ATM switch 3 1 of ATM 
network 27. 

In Fig. 1, IP signaling paths are indicated with dotted lines and ATM of signaling paths are 
indicated with dashed lines. IP media paths are indicated with solid lines and ATM media paths are 
indicated with bold solid lines. 
30 In the embodiment of Fig. 1, a Quality of Service (QoS) connection is provided by routing 

traffic on the QoS capable backbone provided by ATM network 27. According to the present 
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invention, an ATM connection is created for the IP telephony session between user clients 21 and 23. 
QoS extensions to the data network applications part (DNAP) protocol perform the signaling between 
MSCP 13 and access control managers 25 and 27. The access control managers 25 and 27 establish 
the ATM QoS capable connection. While in die preferred embodiment of present invention, the QoS 
capable connection is provided by ATM switched virtual circuits, the present invention can also be 
implemented in a variety of other technologies, such as SONET, and wave division multiplexing. 

As will be explained in detail hereinafter, the data path for the session is secured against 
unauthorized traffic by the use of proxy addressing. The proxy addressing requires translation by the 
access control managers 25 and 27 to route the media to its intended destination. During xssion 
establisliment, die addresses of the media stream endpoints are exchanged between user client 21 and 
user client 23. The signaling message containing the media address of user client 21 is changed to 
rcilect a proxy address, which is an interface at egress excess control manager 27. The excess control 
manager interface is assigned on a per session basis. The per session interface uniqueness is 
accomplished by the allocation and deallocating of ephemeral ports at the access control managers. 
1 5 Associated with the ephemeral ports are the addresses used to create and transit the ATM connection. 
Likewise, die signaling message containing die media address for user client 23 is changed to reflect a 
proxy address at ingress access control manager 25 . 

The system of the present invention dynamically configures QoS connections and ensures their 
security in two ways. First, die QoS connection is dynamically configured by the use of ATM switched 
virtual connections. The switched virtual connections are created on a per session basis during call 
establisliment MSCP 13 invokes the IP to ATM interface mechanisms of access control managers 25 
and 27 with DNAP QoS messages. As will be explained in detail hereinafter, access control manager 
25 launches a user network interface (UNI) protocol setup. The ATM traffic sent to and received by 
access control managers 25 and 27 is intercepted by ATM switches 29 and 31, respectively, and 
25 forwarded to their associated ATM MSCPs 17 and 19. .The ATM MSCPs create the switched virtual 
circuit between ATM switches 29 and 3 1. Access control managers 25 and 27 map the media stream 
of the session to its switched virtual circuit and the session traffic transits their respective switch virtual 
circuit 

The second aspect of the real-time configuration solution is the dynamic securing of the access 
30 to the connections. This is done by dynamically allocating the proxy addresses during session 
establisliment from a pre-provisioned proxy address pool. The proxy addresses are returned to the 
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user clients 21 and 23 in the signaling messages. The session proxy address mapping is created at the 
MSCP and communicated to access control managers 25 and 27 by the DNAP protocol. The proxy 
addresses and the actual session addresses are held at the SIP server 15 and the access control 
managers 25 and 27 for the duration of the session. When the session is terminated, proxy addresses 
are deallocate. 

Referring now to Fig. 2, there is shown a call flow diagram of session initiation according to 
the embodiment of F.g. 1. User client 21 initiates die session by sending a SIP INVITE message 33 to 
user client 23. For purposes of illustration, die IP address of user client 21 is A@XY2.COM. The SIP 
INVITE is addressed to user client 23 at a proxy address at MSCP SIP server 15, which for puiposes 
to illustration is B@XYZ-S1P.COM. The SIP INVITE specifies the audio source as the real IP 
address of user client 21, and specifies that QoS is requested. Upon receipt of invite 33, SIP server 15 
sends an invite 35 to the real IP address of user client 23, at B@XYZ2000.COM. Invite 35 specifies 
the audio source as a temporary IP proxy address allocated to user client 21 at egress access control 
manager 27, which for purposes of illustration is A@ACM-Y.COM. If user client 23 accepts the 
session, user client 23 sends a 200OK SIP response 37 back to SIP SERVER 15, specifying an audio 
destination as its real IP address. While in the preferred embodiment, SIP IP telephony signaling is 
used, other IP signaling protocols, such as H.323 may be used. 

Upon receipt of response 37, SIP server 15 allocates a call tag, and sends a reserve bandwidth 
message 39 to ingress ATM MSCP 17. Message 39 specifies the audio destination for the session of 
as a temporary IP proxy address allocated to user client 23 at ingress access control manager 25. For 
purposes of illustration, the temporary IP proxy address allocated user client 23 is 
B@ACM-XCOM The bandwidth reservation message also identifies the call tag and specifies the 
called number for the ATM connection as egress access control manager 27. 

Upon receipt of bandwidth reservation message 39, ingress ATM MSCP 17 sends a QoS setup 
25 request 41 to ingress access control manager 25. Setup request 41 identifies the real source address 
and proxy source address for user client 21. Setup request 41 also identifies the call tag and the called 
party number. Ingress ATM MSCP 17 also sends a QoS setup indication message 43 to egress access 
control manager 27. Setup indication 43 identifies the real destination address and proxy destination 
address for user client 23, as well as the call tag and the called party number for the ATM session. 
30 Egress access control manager 27 responds to setup indication 23 with a setup indication 
acknowledgment 45 back to ingress ATM MSCP 17. Upon receipt of the QoS setup request 41, 
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ingress access control manager 25 sends a user network interface (UNI) protocol setup message 47 to 
ingress ATM switch 29. Upon receipt of UNI setU p message 47. ingress ATM switch 29 sends a 
DNAP setup 49 to ingress ATM MSCP 17. When ingress ATM MSCP 17 responds, as indicated at 
51, ingress ATM switch 29 sends a setup message 53 to egress ATM switch 31. Upon receipt of setup 
message 53. egress ATM switch 31 sends a DNAP setup message 55 to egress ATM MSCP 19 
When egress ATM MSCP 19 responds, as indicated at 57. egress ATM switch 3 1 sends a UNI setup 
message 59 to egress access control manager 27. 

Upon receipt of setup message 59, egress access control manager 27 sends a CONNECT 
message 61 to ingress access control manager 25. Upon receipt of CONNECT message 61, ingress 
access control manager 25 responds to QoS setup request 41 with a QoS setup ' request 
acknowledgment 63 back to ingress ATM MSCP 17. Upon receipt of setup request acknowledgment 
61, ingress ATM MSCP 17 responds to the reserve bandwidth message 39 with a reserve bandwidth 
acknowledgment message 65 back to MSCP SIP server 15. Upon receipt of reserve bandwidth 
acknowledgment 65, SIP server 1 5 deallocate the call tag and sends a SIP 200 OK response 67 back to 
user client 21. The OK response identifies the audio destination as the temporary IP proxy address 
allocated to user clietl 23 at ingress access control manager 25. Then, user client 21 sends IP media 
packets addrersrd to user client 23 at the temporary proxy address at access control manager 25. 
Similarly, user client 23 sends IP media packet addressed to user client 21 at the temporary proxy 
address at egress access control manager 27. 

From the foregoing, it may be seen that the embodiment of Fig. 1 provides QoS for IP 
telephony sessions between IP user clients. Through the use of temporary proxies, user clients 21 and 
23 are unaware that their session is carried on an ATM switched virtual circuit User clients 21 and 23 
use standard SIP messaging and standard proxying for call setup and no special intelligence is required 
on the part of the user-clients 21 and 23. An intelligent network layer makes the system of the present 
25 invention transparent to user clients 2 1 and 23. 

Referring now to Fig. 3, an alternative embodiment of the system of the present invention is 
designated generally by the numeral 71. System 71 includes MSCP indicated generally at 73. MSCP 
73 bcludes an MSCP SIP server 75, an ingress ATM MSCP 77, and an egress ATM MSCP 79. 
Additionally, MSCP 73 includes a policy server 81. MSCP 73 is adapted to establish a QoS IP 
30 telephony session between a calling user client 83 and a called user client 85. 

An ingress router 87 provides an interface between IP user client 83 and an ATM network 89. 
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An egress router 91 provides interface between user client 85 and ATM network 89. Ingress router 
87 provides an interface to an ingress ATM switch 93 of ATM network 89. Similarly, egress router 91 
provides an interface to an egress ATM switch 95 of ATM network 89. 

Referring now to Fig. 4, diere is shown a call flow diagram of session initiation according to 
die embodiment of Fig. 3. User client 83 initiates the session with a Diameter protocol session 
authentication request 97 addressed to MSCP SIP server 75. Server 75 responds with a Diameter 
session authentication response (ticket), as indicated at 99. Then, user client 83 sends a SIP INVITE 
message 101 to user client 85. For purposes of illustration, the IP address of user client 85 is 
A@XYZ.COM. The SIP INVITE 101 is addressed to user client 85 at a proxy address at MSCP SIP 
server 75, which for purposes to illustration is B@XYZ-SIP.COM The SIP INVITE 101 specifies the 
audio source as the real IP address of user client 83, and specifies that QoS is requested. -The SIP 
INVITE 10 1 also includes die authentication ticket received in response to Diameter session 
authentication request 97. Upon receipt of the SIP INVITE 101, SIP server 75 sends an INVITE 103 
to the real IP address of user client 85, at B@XYZ2000.COM INVITE 103 specifies the audio 
source as the IP address of user client 83. If user client 85 accepts the session, user client 85 sends a 
200OK SIP response 105 back to SIP Server 75, specifying an audio destination as its real IP address. 

Upon receipt of 200OK SIP response 105, SEP sender 75 sends a reserve bandwidth message 
107 to MSCP policy server 81. Message 107 specifies the audio source for the session of as die real IP 
address of user client 83, and die audio destination for the session as the real IP address of user client 
85. The message 107 also includes the authentication ticket Upon receipt of the message 107, MSCP 
policy server 81 sends a response 109 back to MSCP SIP server 81. Then, SIP server 75 sends a SIP 
200OK response 1 1 1 to user client 83. 

Upon receipt of 200OK response 111, user client 83 sends a resource reservation protocol 
(RSVP) path message 1 13 to ingress router 87. Then, ingress router 87 sends a COPS request handle 
25 message 115 to MSCP policy server 81. When MSCP policy server 81 responds, as indicated at 117, 
ingress router 87 sends an RSVP path message 1 19 to egress router 91. Then, egress router 91 sends 
an RSVP padi message 121 to user client 85. User client 85 responds with an RSVP reservation 
response 123 back to egress router 91. Egress router 91 then responds with an RSVP reservation 
response 125 back to ingress router 87. 

Upon receipt of response 125, ingress router 87 sends a UNI setup message 127 to ingress 
ATM switch 93. Upon receipt of UNI setup message 127, ingress ATM switch 93 sends a DNAP 
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setup ,29 to ingress ATM MSCP 77. Wl.cn ingress ATM MSCP 77 respond, as bdicated at 131 
■ngress ATM switch 93 sends a setup me ssage ,33 to egress ATM switch 95. Upon receipt of setup 
message 133, egress ATM switch 95 sends a DNAP setup message ,35 to egress ATM MSCP 79 
When egress ATM MSCP 79 responds, as indicated at ,37, egress ATM switch 95 sends a UNI setup 
message ! 39 to egress router 91. 

Upon receipt of setup message ,39, egress router 9, sends a CONNECT message 141 to 
■ngress router 87. Upon receipt of CONNECT message ,41, ingress router 87 responds to RSVP 
pad, message 1, 3 with an RSVP reserve response ,43 back to user client 83. Then. the IP telephony 
session is established between user client 83 and user client 85. 

The embodiment of Figs. 3 and 4, distributes a certain amount of system intelligence to user 
Cents 83 and 85. User clients 83 and 85 are responsible for a greater part of call setup than^re user 
clients 21 and 23 of the embodiment of F,gs. , and 2. User clients 83 and 85 process signaling in 
Diameter and RSVP protocols in addition to signaling in SIP protocol. 

From the foregoing it may be seen that the present invention overcomes the shortcomings of 
the pnor art The present invention dynamically establishes and secures QoS IP telephony sessions by 
routing traffic on a high QoS backbone, which is preferably an ATM backbone. Those skilled in the art 
wrfl recognize alternative embodiments, given the benefit of this disclosure. Accordingly, the foregoing 
disclosure is intended for purposes of illustration and not limitation. 
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WHAT IS CLAIMED IS: 

I 1 . A method of providing quality of service in an Internet Protocol (LP) telephony session 
between a catling party and a called party, which comprises die steps of: 

transporting IP media for said session between said calling party and a first device having IP 

4 capability and ATM capability; 

5 transporting IP media for said session between said called party and a second device having IP 

6 capability and ATM capability, and 

establisliing an ATM virtual circuit for said session between said first device and said second 
8 device. 



2 



7 



1 2. The method as claimed in claim 1 , wherein said first and second devices 



3 



are routers. 



1 3. The method as claimed in claim I, wherein: 

2 said firet device is identified by a temporary session IP proxy address for said called party, and 

3 said second device is identified by a temporary session IP proxy address for said calling party. 

1 4. The method as claimed in claim 1, wherein said step of establishing an ATM virtual circuit 

2 between said first and second devices comprises the steps of 

3 assigning a calling party number for said session at said first device; and 

4 assigning a called party number for said session at said second device. 



1 5. A method of providing quality of service in an LP telephony session between a calling party and 

2 a called party, which comprises the steps of: 
assigning a temporary IP proxy address for said called party for said session at a first access 



4 control manager, 

5 assigning a temporary IP proxy address for said calling party for said session at a second access 

6 control manager, and 

7 establishing a switched virtual circuit for said session between said first access control manager 

8 and said second access control manager. 
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1 6. The method as claimed in claim 5, wherein said step of establisliing said virtual circuit 

2 comprises the steps of: 

3 assigning a temporary calling party address for said session at said first access control manager 

4 and ^ 

5 assigning a temporary called party address for said session at said first access control manager. 

1 7. The method as claimed in claim 6, wherein said step of assigning a temporary calling party 

2 address comprises the step of selecting a calling parry address from a pool of calling party addresses 

3 allocated to said first access manager. 

1 3. The method as claimed in claim 6, wherein said step of assigning a temporary called party 

2 address comprises the step of selecting a called party address from a pool of called party addresses 

3 allocated to said second access manager. 

1 9. The method as claimed in claim 5, further comprising the steps of: 

2 routing IP met! i traffic from said calling party to said called party IP proxy address at said first 

3 access control manager; and 

4 routing IP media traffic from said called parry to said calling party IP proxy address at said 

5 second access control manager. 

1 10. The method as claimed in claim 9, further comprising the steps of: 

2 translating IP media traffic received at said called party IP proxy address to ATM traffic for 

3 transport through said virtual circuit from said first access control manager to said second access 

4 control manager, and' 

5 translating IP media traffic received at said calling party IP proxy address to ATM traffic for 

6 transport through said virtual circuit from said second access control manager to said first access 

7 control manager. 
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1 II. The method as claimed in claim 1 0, further comprising the steps of: 

2 translating ATM traffic received at said temporary called party address to IP media traffic for 

3 transport to said called party; and 

4 translating ATM traffic received at said temporary calling party address to IP media traffic for 

5 transport to said calling party. 

1 1 2. A method of providing quality of service in an IP telephony session between a calling party and 

2 a called party, which comprises the steps of 

3 assigning a temporary IP proxy address for said called party for said session at a first access 

4 control manager, 

5 assigning a temporary IP proxy address for said calling party for said session a second access 

6 control manager, 

7 assigning a temporary second network calling party address for said session at said first access 

8 control manager, and 

9 assigning a temporary second network called party address for said session at said first access 

1 0 control manager. 

1 13. The method as claimed in claim 12, wherein said step of assigning a temporary second network 

2 calling party address comprises the step of selecting a calling party address from a pool of second 

3 network calling party addresses allocated to said first access manager. 

1 14. The method as claimed in claim 12, wherein said step of assigning a temporary second network 

2 called party address comprises the step of selecting a called party address from a pool of second 

3 network called party addresses allocated to said second access manager. 

1 15. The method as claimed in claim 12, further comprising the steps of: 

2 routing IP media traffic from said calling party to said called party IP proxy address at said first 

3 access control manager, and 

4 routing IP media traffic from said called party to said calling party IP proxy address at said 

5 second access control manager. 
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16. 



The method as claimed in claim 15, wherein: 



2 said second network includes an ATM network; 



said temporary second network calling party address includes a temporary calling party 
4 number, and 



said temporary second network called party address includes a temporary called party number. 

17. The method as claimed in claim 16, further comprising the step of establishing a switched 
virtual connection through said ATM network between said temporary called party number and said 



3 temporary calling party number. 



18. The method as claimed in claim 1 7, further comprising the steps of: 

translating IP media traffic received at said called party IP proxy address to ATM traffic for 
transport through said virtual circuit from said first access control manager to said second access 

4 control manager, and 

5 translating IP media traffic received at said calling party IP proxy address to ATM traffic for 
transport through said virtual circuit from said second access control manager to said first access 

7 control manager. 

1 1 9. The method as claimed in claim 1 7, further comprising the steps of: 

2 translating ATM traffic received at said temporary called party number to IP media traffic for 

3 transport to said called party, and 

4 translating ATM traffic received at said temporary calling party number to IP media traffic for 

5 transport to said calling party. 
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1 20. A system for providing a quality of service IP telephony session between a calling party and a 

2 called party, which comprises: 

3 an IP network, said IP network providing EP access to the calling party and to the called party; 

4 an ATM network; 

5 a first device connected between said IP network and said ATM network, said f.rst device 

6 ' providing bidirectional translation between IP media traffic and ATM traffic; 

7 a second device connected between said IP network and said ATM network, said second 

8 device providing bidirectional translation between ATM traffic and IP media traffic; and 

9 an intelligent control layer for establishing a virtual circuit through said ATM network for an IP 
1 0 telephony session between the calling party and the called party. 

1 21. The system as claimed in claim 20, wherein: 

2 said first device is operably connected to an ingress switch of said ATM network; and 
said second device is operably connected to an egress switch of said ATM network. 



3 



1 

2 



22. The system as claimed in claim 20, wherein said intelligent control layer comprises: 

an ATM intelligent controller, said ATM intelligent controller providing session setup signaling 



3 to said first and second devices; and 

4 an IP intelligent controller, said IP intelligent controller providing call setup signaling to said 

5 ATM intelligent controller. 



1 23. The system as claimed in claim 20, wherein in said first and second devices each comprise a 

2 router. 



1 24. The system as claimed in claim 20, wherein said intelligent control means comprises: 

2 means for assigning a temporary IP session proxy address for said called party at said first 

3 device; and 

4 means for assigning a temporary IP session proxy address for said calling party at said second 

5 device. 
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1 RSVP PROXY SERVICE FOR COMMUNICATION NETWORK 

BACKGROUND OF THE INVENTION 

Data communication switches are becoming more and more intelligent. Whereas legacy 

5 data communication switches provided indiscriminate first- in, first-out forwarding of packets, 
more recent data communication switches support differential packet forwarding based on flow 
characteristics under the Quality of Service (QoS) label. The trend toward QoS started first in 
cell-switched ATM networks, but has migrated to packet-switched networks and protocols, 
including bridging (Layer 2, or "L2"), routing (Layer 3. or "L3") and transport (Layer 4, or "L4 tt ) 

10 protocols. 

Standardized QoS elements are emerging in packet switched networks. One standard 
element is a signaling protocol through which a QoS may be provisioned end-to-end for a flow. 
This signaling protocol is called the Resource Reservation Protocol (RSVP). In conventional 
RSVP-signaled QoS provisioning, an RSVP-aware source host called a "sender", desiring to 

1 5 initiate a flow with an RSVP-aware destination host called a "receiver", transmits downstream 
an RSVP Path message specifying parameters for a proposed flow. Switches along the flowpath 
review the RSVP Path message and modify certain message fields as required to indicate 
limitations and conditions on their ability to deliver QoS services to the flow. The RSVP-aware 
destination host receives the RSVP Path message and uses the information therein to generate 

20 and transmit an RSVP Resv message back upstream requesting the provisioning of a specific 
QoS for the flow at each switch along the flowpath. Each switch determines whether or not to 
accept the request based on whether the switch has sufficient available resources to provide the 
requested QoS and whether the flow is entitled to the requested QoS. If the reservation is 
accepted, the switches are configured to forward packets within the flow in accordance with the 

25 QoS. In this way. an RSVP-signaled QoS for the flow is provisioned end-to-end along the 
flowpath. 

While standard RSVP-signaled QoS. as oudined above, provides a means for end-to-end 
QoS provisioning within a network, it is only known to be available for flows between hosts that 
are RSVP-aware. There is a need to extend the benefits of RSVP-signaled QoS to flows 
30 involving RSVP-unaware hosts. 

SUMMARY OF THE INVENTION 

The present invention provides RSVP host proxy services for extending RSVP-signaled 
QoS provisioning to flows involving hosts that are not RSVP-aware. 
35 In accordance with an RSVP sender host proxy service, a switch through which a first host 

accesses a network acts as an RSVP sender host proxy for the first host. Upon receiving a data 
packet for a new flow from the first host, and determining that the RSVP sender host proxy 
service is enabled for the first host the switch generates and transmits on a flowpath to a second 
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1 host an RSVP Path message. In accordance with RSVP, the RSVP Path message prompts the 
second host to generate and return on the flowpath an RSVP Resv message. 

In accordance with an RSVP receiver host proxy service, a switch through which a first 
host accesses a network acts as an RSVP receiver host proxy for the first host. Upon receiving 
5 an RSVP Path message generated and transmitted by a second host and determining that the 
RSVP receiver host proxy service is enabled for the first host, the switch generates and returns 
" on a flowpath to the second host an RSVP Resv message. 

A switch serving as an RSVP host proxy for a host may continue to act as an RSVP router 
for hosts. 

10 These and other aspects of the inventions may be better understood by reference to the 

following detailed description taken in conjunction with the accompanying drawings briefly 
described below. 



BRIEF DESCRIPTION OF THE DRAWINGS 
15 Figure 1 illustrates a network in which an RSVP sender host proxy service is operative; 

Figure 2 illustrates a switch supporting an RSVP sender host proxy function in the 
network according to Figure 1 ; 

Figure 3a illustrates the general format for a packet including an RSVP Path message; 
Figure 3b illustrates the general format for a packet including an RSVP Resv message; 
20 Figure 4 illustrates a network in which an RSVP receiver host proxy service is operative; 

Figure 5 illustrates a switch supporting an RSVP receiver host proxy function in the 
network according to Figure 4; 

Figure 6 is a flow diagram describing RSVP packet handling on a switch supporting an 
RSVP sender host proxy function in accordance with a preferred embodiment of the invention; 
25 and 

Figure 7 is a flow diagram describing RSVP packet handling on a switch supporting an 
RSVP receiver host proxy function in accordance with a preferred embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
30 In Figure 1 , a network is shown in which a preferred RSVP sender host proxy service in 

accordance with the invention is operative. The network includes RS VP-unaware source host 1 1 0 
having access to backbone network 1 30 via edge switch 1 40. Edge switch 1 40 is coupled to edge 
switch 160 across backbone network 130 via one or more core switches (not shown) operative 
in backbone network 1 30. Edge switch 1 60 is coupled to RSVP-aware destination host 1 20. Edge 
35 . switches 1 40, 1 60 are also coupled to policy servers 1 50, 1 70, respectively. 

Hosts 1 10, 120 are preferably network end-stations, such as PCs, workstations or servers, 
having respective network interfaces for packetized communication with other hosts via edge 
switches 140, 160, respectively. Edge switches 140, 160 are preferably gateway devices, such as 
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1 hubs, bridges or routers, having a plurality of respective network interfaces for forwarding 
packetized communications originated by hosts. Policy servers 1 50, 1 70 retain quality of service 
(QoS) rules for application on edge switches 140, 160, respectively, based on flow 
characteristics. Hosts 110, 120, edge switches 140, 160 and policy servers 150, 170 may be 

5 interconnected via cables or other transmission media, and may support various data 
communication protocols, such as Ethernet, Internet Protocol (IP) and Asynchronous Transfer 
Mode (ATM). Edge switches 140, 160 preferably support the router function of Resource 
Reservation Protocol (RSVP) set forth in Internet Engineering Task Force Request for Comment 
2205 entitled "Resource ReSerVation Protocol - Version 1 Functional Specification", September 

1 0 1 997 (hereinafter RFC 2205), incorporated herein by reference. Destination host 1 20 preferably 
supports the RSVP receiver host function set forth in RFC 2205; however, source host 1 10 does 
not support the RSVP sender host function set forth in RFC 2205. Instead, RS VP-signaled end- 
to-end QoS provisioning for data flows between source host 1 10 and destination host 120 is 
established through the expedient of an RSVP sender host proxy agent implemented on edge 

15 switch 140. 

In its most basic feature, the RSVP sender host proxy service may be described with 
reference to Figure 1 . RS VP-unaware source host 1 1 0 initiates a data flow by transmitting a data 
packet on the transmission medium interconnecting source host 1 10 with edge switch 140, the 
data packet having an address of source host 110 as a source address and an address of 

20 destination host 120 as a destination address. Edge switch 140 receives the data packet, 
determines that the data packet meets RSVP sender host proxy criteria, generates an RSVP Path 
message in accordance with an RSVP sender host function, modifies certain fields of the RSVP 
Path message if required in accordance with an RSVP router function, and transmits the RSVP 
Path message on backbone network 130. The RSVP Path message traverses backbone network 

25 130 and edge switch 160 along a flowpath between source host 1 10 and destination host 120, 
whereat certain fields of the message may be modified at each "hop" in accordance with the 
RSVP router function, and eventually arrives at RS VP-aware destination host 120. Destination 
host 120, in response to the RSVP Path message, generates an RSVP Resv message requesting 
a QoS reservation in accordance with the RSVP receiver host function and transmits the RSVP 

3 0 Resv message on the transmission medium interconnecting destination host 1 20 and edge switch 
160. Edge switch 160 receives the RSVP Resv message and, in conjunction with policy server 
170 and in accordance with the RSVP router function, determines whether or not to accept the 
reservation. The RSVP Resv message traverses backbone network 130 and edge switch 140 
along the flowpath, whereat it is determined at each "hop" in accordance with the RSVP router 

35 function whether to accept the reservation, with edge switch 140 making the determination in 
conjunction with policy server 1 50. 

Various elaborations of this basic RSVP sender host proxy service are possible as 
described hereinafter. Nevertheless, at a fundamental level, this basic proxy service, despite its 
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apparent simplicity, is believed to confer a significant advance over the prior art by expanding 
the reach of RSVP-signaled QoS provisioning to flows involving source hosts that are RSVP- 
unaware. 

Turning now to Figure 2 a preferred RSVP sender host proxy service will be described in 
even greater detail by reference to "on switch" processing on edge switch 140. Edge switch 140 
has network interfaces 210, 220, 230 and management interface 240 linked by data bus 250. 
Network interfaces 210, 220, 230 interconnect RSVP-unaware source host 110, switches in 
backbone network 1 30 and policy server 1 50 over different interfaces. Management interface 240 
supports various modules, including QoS mapper/classifier 241, QoS manager 242, policy 
manager 243, QoS driver 244, source learning 245 and RSVP 246. RSVP 246 includes RSVP 
router agent 247 and RSVP sender host proxy agent 248. Management interface 240 and network 
interfaces 210, 220, 230 are linked by management bus 260 for transmitting and receiving 
management information including QoS information for various flows. 

Edge switch 140 supports RSVP processing as follows. RSVP message packets received 
on edge switch 140 are captured off data bus 250 by management interface 140. RSVP message 
packets are forwarded to RSVP 246 for processing by RSVP routing agent 247 in accordance 
with the RSVP router function. RSVP router function processing of RSVP Path message packets 
includes modifying certain message fields as required to indicate limitations and conditions on 
the ability of switch 140 to deliver QoS services to the flow. RSVP router function processing 
of RSVP Resv message packets includes determining whether or not to accept requested QoS 
reservations based on whether switch 140 has sufficient available resources to provide the 
requested QoS and whether the flows in question are entitled to the requested QoS. The 
determination of whether or not to accept QoS reservations is made in concert with QoS manager 
242 and policy manager 243. Rules defining applicable QoS limitations and conditions are 
"pulled down" to policy manager 243 from policy server 1 50 and applied in the determination. 
RSVP router function forwards RSVP Path message packets, including any modifications, to the 
"next hops" in the network, and forwards RSVP Resv message packets, including any 
modifications, to the "previous hops" in the network. 

QoS manager 242 facilitates QoS establishment on switch 140 in accordance with 
accepted QoS reservations. For flows for which reservations have been accepted, QoS manager 
242 receives from policy manager 243 QoS policies, divides the QoS policies into flow identifier 
and QoS parts and forwards the parts to the QoS mapped classifier 24 1 . Mapped classifier 24 1 
associates the flow identifiers with queues supporting the QoS and forwards the associations to 
QoS driver 244, which establishes flow identifier/queue associations on network interfaces 210, 
220, 230 via management bus 260 to implement the QoS policies on switch 140. 

In addition to the RSVP processing described above, edge switch 140 supports a novel 
RSVP sender host proxy function as follows. Data packets received on switch 140 and having 
unknown source addresses are captured off data bus 250 by management interface 1 40. Unknown 
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1 source address data packets are forwarded to source learning 245 for establishing associations 
on switch 140 between the source addresses and the network interfaces on which the source 
addresses arrived. Unknown source address data packets are also forwarded to QoS manager 242 
to determine whether the RSVP sender host proxy function is enabled for the sources in question. 

5 Where enabled, unknown source address packets are forwarded to RSVP sender host proxy agent 
248 for processing in accordance with an RSVP sender host function. RSVP sender host function 
processing includes generating RSVP Path message packets specifying parameters for the flows 
in question and forwarding RSVP Path message packets for processing by RSVP routing agent 
247 in accordance with the RSVP router function as described earlier. 

1 0 Turning to Figure 3a. the general format of an RSVP Path message packet is shown. The 

format and content of such a packet is well known and described in RFC 2205. Generally such 
a packet generally includes a Layer 2 header 310 followed by a Layer 3 header 320 and RSVP 
Path message 330. Layer 2 header 310 includes source and destination addressing information. 
Layer 3 header 320 is generally an IP header including source and destination addressing 

15 information and specifying protocol number "46". RSVP Path message 330 includes an RSVP 
common header identifying the message as a Path message and an RSVP object including the 
contents of the Path message. The contents of the Path message include a Sender TSPEC 
describing the flow the sender expects to generate and an ADSPEC. The Sender TSPEC traverses 
the flowpath from the RSVP sender to the RSVP receiver without modification, whereas the 

20 ADSPEC may be modified by switches along the flowpath to indicate the availability of QoS 
control services and parameters required for QoS control services to operate correctly. 

Turning to Figure 3 b. the general format of an RSVP Resv message packet is shown. The 
format and content of such a packet is well known and described in RFC 2205. Generally such 
a packet generally includes a Layer 2 header 340 followed by a Layer 3 header 350 and RSVP 

25 Resv message 360. Layer 2 header 340 includes source and destination addressing information. 
Layer 3 header 340 is generally an IP header including source and destination addressing 
information and specifying protocol number "46". The RSVP Path message 350 includes an 
RSVP common header identifying the message as a Resv message and an RSVP object including 
the contents of the Resv message. The contents of the Resv message include a requested QoS 

30 control service, a Receiver TSPEC describing the flow for which resources should be reserved 
and, if indicated by the requested QoS control service, a Receiver RSPEC describing the level 
of service being requested. The contents together form a FLO WSPEC that traverses the flowpath 
from the RSVP receiver to the RSVP sender and may be modified by switches along the 
flowpath. 

35 Turning now to Figure 4. a network is shown in which a preferred RSVP receiver host 

proxy service in accordance with the invention is operative. The network includes an RSVP- 
unaware destination host 410 having access to backbone network 430 via edge switch 440. Edge 
switch 440 is coupled to edge switch 460 via one or more core switches (not shown) in backbone 
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1 network 430. Edge switch 460 is coupled to RSVP-aware source host 420. Edge switches 
440,460 are also coupled to policy servers 450,470, respectively. 

Hosts 4 1 0, 420 are preferably network end-stations, such as PCs, workstations or servers, 
having respective network interfaces for packetized communication with other hosts via edge 

5 switches 440, 460, respectively. Edge switches 440. 460 are preferably gateway devices, such as 
hubs, bridges or routers, having a plurality of respective network interfaces for forwarding 
packetized communications originated by hosts. Policy servers 450, 470 retain quality of service 
(QoS) rules for application on switches 440, 460, respectively, based on flow characteristics. 
Hosts 410, 420, switches 440, 460 and policy servers 450, 470 may be interconnected via cables 

10 or other transmission media, and may support various protocols, such as Ethernet, IP and ATM. 
Edge switches 440, 460 preferably support the RSVP router function set forth in RFC 2205. 
Source host 420 preferably supports the RSVP sender host function set forth in RFC 2205; 
however, destination host 41 0 does not support the RSVP receiver host function set forth in RFC 
2205. Consequently, end-to-end QoS provisioning for data flows between source host 420 and 

1 5 destination host 4 1 0 is established through the expedient of an RSVP receiver host proxy agent 
implemented on edge switch 440. 

In its most basic feature, the RSVP receiver host proxy service may be described with 
reference to Figure 4. RSVP-aware source host 420 generates in accordance with the RSVP 
sender host function an RSVP Path message having an address of RS VP-unaware destination 

20 host 410 as a destination address and transmits the RSVP Path message on the transmission 
medium interconnecting source host 420 with switch 460. Switch 460 receives the RSVP Path 
message, modifies certain fields of the message if required in accordance with the RSVP router 
function, and transmits the RSVP Path message on backbone network 430. The RSVP Path 
message traverses switches along the flowpath in backbone network 430 hop-by-hop whereat 

25 certain fields of the message may be modified in accordance with the RSVP router function, and 
eventually arrives at switch 440. Switch 440 modifies certain fields of the message in accordance 
with the RSVP router function, determines that the RSVP Path message packet meets RSVP 
receiver host proxy criteria, and generates in response an RSVP Resv message in accordance with 
the RSVP receiver host function. Switch 440 determines, in conjunction with policy server 450 

30 and in accordance with the RSVP router function, whether to accept the reservation itself prior 
to transmitting the RSVP Resv message back up the flowpath on backbone network 430. The 
RSVP Resv message traverses switches in backbone network 430 and switch 460, whereat it is 
determined hop-by-hop in accordance with the RSVP router function whether to accept the 
reservation, with switch 460 making the determination in conjunction with policy server 470. 

35 Various elaborations of this basic RSVP receiver host proxy service are possible as 

described hereinafter. Nevertheless, at a fundamental level, this basic proxy service, despite its 
apparent simplicity, is believed to confer a significant advance over the prior art by expanding 



-6- 




+ 



WO 01/31829 



PCT/US00/41389 



i 

5 



10 



15 



20 



25 



30 



the reach of RSVP to allow end-to-end QoS provisioning for flows involving a destination host 
that is RSVP- 



Turning now to Figure 5 a preferred RSVP receiver host proxy service will be described 
in greater detail by reference to "on switch" processing on edge switch 440. Switch 440 has 
network interfaces 5 10, 520, 530 and management interface 540 linked by data bus 550. Network 
interfaces 510, 520, 530 interconnect destination host 410, switches in backbone network 430 
and policy server 450 over different interfaces. Management interface 540 supports various 
modules, including QoS mapper/classifier 541, QoS manager 542, policy manager 543, QoS 
driver 544, source learning 545 and RSVP 546. RSVP 546 includes an RSVP router agent 547 
and an RSVP receiver host proxy agent 548. Management interface 540 and network interfaces 
510, 520, 530 are linked by management bus 560 for transmitting and receiving management 
information including QoS information for various flows. 

Switch 440 supports RSVP processing as follows. RSVP message packets received on 
switch 440 are captured off data bus 550 by management interface 540. RSVP message packets 
are forwarded to RSVP 546 for processing by RSVP routing agent 547 in accordance with the 
RSVP router function, subject to exceptions specified herein. In the case of RSVP Path message 
packets, RSVP router function processing includes modifying certain fields in the Path message 
as required to indicate limitations and conditions on the ability of switch 540 to deliver QoS 
services to the flow. In the case of RSVP Resv message packets, RSVP router function 
processing includes determining whether or not to accept requested QoS reservations based on 
whether switch 440 has sufficient available resources to provide the requested QoS and whether 
the flows in question are entitled to the requested QoS. The determination of whether or not to 
accept QoS reservations is made in concert with QoS manager 542 and policy manager 543. 
Rules defining applicable QoS limitations and conditions are "pulled down" to policy manager 
543 from policy server 450 and applied in the determination. RSVP router function forwards 
RSVP Resv message packets, including any modifications, to the "previous hops" in the network. 
RSVP router function also forwards RSVP Path message packets, including any modifications, 
to the "next hops" in the network, except where the RSVP receiver host proxy function is enabled 
for the destinations in question. Where enabled, RSVP Path messages are not forwarded to the 
"next hops" in the network. 

In addition to the RSVP processing described above, switch 440 supports a novel RSVP 
receiver host proxy function as follows. RSVP Path message packets are forwarded to QoS 
manager 542 to determine whether the RSVP receiver host proxy function is enabled for the 
destinations in question. Where enabled, RSVP Path message packets are forwarded to RSVP 
receiver host proxy agent 548 for processing in accordance with an RSVP receiver host function. 
RSVP receiver host function includes generating RSVP Resv message packets in response to the 
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1 RS VP Path message packets and forwarding the RS VP Resv message packets for processing by 
RSVP routing agent 547 in accordance with the RSVP router function as described earlier. 

In Figure 6, a flow diagram illustrates RSVP packet handling on a switch supporting an 
RSVP sender host proxy function in accordance with a preferred embodiment of the invention. 

5 A packet is received on the switch (610) and a determination is made whether the packet is an 
RSVP message packet (620). If the packet is an RSVP message packet, the packet is processed 
in accordance with the RSVP router function (650). If the packet is not an RSVP message packet, 
a determination is made whether the packet has a source address that is unknown to the switch, 
indicating a new flow for which a QoS has not yet been provisioned (630). If the packet has an 

1 0 unknown source address, a determination is made whether the RSVP sender host proxy service 
is enabled for the source (640). If the RSVP sender proxy service is enabled for the source, an 
RSVP Path message packet is generated (650). The RSVP Path message is processed by the 
switch in accordance with the RSVP router function (660). If, however, the source address is 
known to the switch (per the determination in Step 630), or if the RSVP sender host-proxy 

1 5 service is not enabled for the source (per the determination in Step 640), RSVP processing of the 
received packet is terminated. 

In Figure 7, a flow diagram illustrates RSVP packet handling on a switch supporting an 
RSVP receiver host proxy function in accordance with a preferred embodiment of the invention. 
A packet is received on the switch (710) and a determination is made whether the packet is an 

20 RSVP message packet (720). If the packet is an RSVP message packet, a determination is made 
whether the packet is an RSVP Path message packet (730). If the packet is not an RSVP Path 
message packet, RSVP processing of the received packet proceeds in accordance with the RSVP 
router function (740). If the packet is an RSVP Path message packet however, a determination 
is made whether the RSVP receiver host proxy service is enabled for the destination (750). If the 

25 RSVP receiver host proxy service is not enabled for the destination, RSVP processing of the 
received packet proceeds in accordance with the RSVP router function (740). If the RSVP 
receiver host proxy service is enabled for the destination, however, RSVP processing of the 
received packet proceeds in accordance with the RSVP router function except the Path message 
is not forwarded by the switch to the "next hop" in the network (760), and an RSVP Resv 

30 message packet is generated (770). The RSVP Resv message is processed by the switch in 
accordance with the RSVP router function (780). 

It will be appreciated by those of ordinary skill in the art that the invention can be 
embodied in other specific forms without departing from the spirit or essential character hereof. 
For instance, while the illustrated embodiments describe RSVP proxy-signaled end-to-end QoS 

3 5 provisioning for unicast flows between a source host and a single destination host, the invention 
may be applied to multicast flows between a source host and multiple destination hosts, wherein 
one or more switches act as RSVP host proxies for the source host and/or one or more of the 
destination hosts. The present description is therefore considered in all respects illustrative and 
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not restrictive. The scope of the invention is indicated by the appended claims, and all changes 
that come within the meaning and range of equivalents thereof are intended to be embraced 
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We claim: 

1. A Resource Reservation Protocol (RSVP) proxy method for a communication 
network having a plurality of nodes, the method comprising: 

generating a data packet on a first node; 
transmitting the data packet to a second node; 

determining on the second node in response to the data packet whether the second node 
is an RSVP proxy for the first node; 

generating an RSVP Path message in response to the determination; and 
transmitting the RSVP Path message to a third node. 

2. The method^of claim 1, wherein the first node is a host and the second node is a 
switch. 

3. The method of claim 1 , wherein the determination is made in accordance .with a 
source address in the packet. 

4. A Resource Reservation Protocol (RSVP) proxy method for a communication 
network having a plurality of nodes, the method comprising: 

generating an RSVP Path message on a first node; 
transmitting the RSVP Path message to a second node; 

determining on the second node in response to the RSVP Path message whether the second 
node is an RSVP proxy for a third node; 

generating an RSVP Resv message in response to the determination; and 
transmitting the RSVP Resv message to the first node. 

5 . The method of claim 4. wherein the first node and the third node are hosts and the 
second node is a switch. 

6. The pethod of claim 4, wherein the detennination is made in accordance with a 
destination address in the packet. 

7. An RSVP proxy method for a communication network having a plurality of hosts 
and a switch, the method comprising: 

transmitting a data packet from a first host to a switch; 

originating an RSVP Path message on the switch in response to the data packet; 
transmitting the RSVP Path message from the switch to a second host; and 
transmitting an RSVP Resv message from the second host to the switch in response to the 
RSVP Path message. 
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1 8. The method according to claim 7, wherein the first host is RSVP -unaware. 

9. The method according to claim 7, further comprising reserving resources along a 
flowpath between the second host and the switch in response to the RSVP Resv message. 

5 

1 0. An RSVP proxy method for a communication network having a plurality of nodes, 
the method comprising: 

transmitting an RSVP Path message from a first host to a switch; 
originating an RSVP Resv message on the switch in response to the RSVP Path message; 
1 0 transmitting the RSVP Resv message from the switch to the first host 

1 1 . The method according to claim 1 0, wherein the first host is RSVP -unaware. 

12. The method according to claim 1 1, further comprising reserving resources-along 
1 5 a flowpath between the first host and the switch in response to the RSVP Resv message. 

13. An RSVP proxy service for a communication network, comprising: 
a host for transmitting a data packet; 

an edge switch for receiving the data packet from the host; 
20 an RSVP host proxy agent on the edge switch for generating and transmitting to a 

backbone network, in response to the data packet, an RSVP Path message. 

14. An RSVP proxy service for a communication network, comprising: 
a host for transmitting an RSVP Path message; 

25 an edge switch for receiving the RSVP Path message from a backbone network; 

an RSVP host proxy agent on the edge switch for generating and transmitting to the 
backbone network, in response to the RSVP Path message, an RSVP Resv message. 

1 5. An RSVP proxy service for a communication network, comprising: 

30 a host connected to an edge switch, the edge switch managing the flow of data packets 

from the host to a backbone network; and 

wherein the edge switch receives a data packet from the host and in response generates and 
transmits an RSVP Path message on the backbone network. 

35 1 6. An RSVP proxy service for a communication network, comprising: 

a host connected to an edge switch, the edge switch managing the flow of data packets 
from the host to a backbone network; and 
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wherein the edge switch receives an RSVP Path message destined for the host from the 
backbone network and in response generates and transmits an RSVP Resv message on the 
backbone network. 

1 7. An RSVP proxy service for a communication network, comprising: 

a first node connected to a second node, the second node providing an interface between 

the first node and a backbone network; and 

wherein the second node receives a data packet from the first node and in response 

generates and transmits an RSVP Path message on the backbone network. 



18. An RSVP proxy service for a communication network, comprising: 

a first node connected to a second node, the second node providing an interface between 
the first node and a backbone network; and 

wherein the second node receives an RSVP Path message destined for the first node from 
1 5 the backbone network and in response generates and transmits an RSVP Resv message on the 
backbone network. 

1 9. A signaling method for establishing an end-to-end Quality of Service (QoS) for a 
data flow in a communication network utilizing a signaling proxy, the method comprising: 

20 generating a data packet on a first node; 

transmitting the data packet to a second node; 

determining on the second node in resppnse to the data packet whether the second node- 
is a QoS signaling proxy for the first node; 

generating a QoS message in response to the determination; and 
25 transmitting the QoS message to a third node. 

20. The method of claim 1 9, wherein the first node is a host and the second node is a 
switch. 

30 21. The method of claim 20, wherein the determination is made in accordance with a 

source address in the packet. 



22. The method of claim 20, wherein the QoS message specifies parameters for a data 

flow. 

23. The method of claim 20, wherein the QoS message is modified in route to the third 

node. 



-12- 



WO 01/31829 



PCT/US00/41389 



24. A signaling method for establishing an end-to-end Quality of Service (QoS) for a 
data flow in a communication network utilizing a signaling proxy, the method comprising: 

generating a first QoS message on a first node; 
transmitting the first QoS message to a second node; 

determining on the second node in response to the QoS message whether the second node 
is a QoS signaling proxy for a third node; 

generating a second QoS message in response to the determination; and 
transmitting the second QoS message to the first node. 

25. The method of claim 24, wherein the first node and the third node are hosts and the 
second node is a switch. 

26. The method of claim 24. wherein the determination is made in accordance with a 
destination address in the first QoS message. 

27. The method of claim 24. wherein the first QoS message specifies parameters for 
a data flow. 

28 . The method of claim 24. wherein the first QoS message is modified in route to the 
second node. 

29. The method of claim 24, wherein the second QoS message requests establishment 
of a QoS for a data flow. 

30. The method of claim 24. wherein a QoS is established for a data flow at nodes 
along a flowpath between the second node and the first node in response to the second QoS 
message. 

31. A service for establishing end-to-end QoS in a communication network, 
comprising: 

a host connected to an edge switch, the edge switch managing the flow of data packets 
from the host to a backbone network; and 

wherein the edge switch receives a data packet from the host and in response generates and 
transmits a QoS message on the backbone network. 

32. The service according to claim 3 1 , wherein the QoS message specifies parameters 
for a data flow. 

33. A service for establishing end-to-end QoS in a communication network, comprising: 
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a host connected to an edge switch, the edge switch managing the flow of data packets 
from the host to a backbone network; and 

wherein the edge switch receives a first QoS message destined for the host from the 
backbone network and in response generates and transmits a second QoS message on the 
backbone network. 

34. The -service according to claim 33, wherein the first QoS message specifies 
parameters for a data flow. 

35. The service according to claim 33, wherein the second QoS message requests 
establishment of a QoS for a data flow. 
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Figure 3A 
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